LoopPeel sometimes proves that, when reached, the original loop always
executes at least two iterations. LoopPeel then unconditionally executes
both the remaining loop's initial iteration and the peeled final
iteration. But that increases the latter's frequency above its frequency
in the original loop. To maintain the total frequency, this patch
compensates by decreasing the remaininng loop's latch probability.

This is another step in issue #135812 and was discussed at
<#166858 (comment)>.

…68760)

This reverts commit eb20b53.

This relands the compiler-rt internal shell after XRay and Darwin tests
that were failing under the internal shell have been fixed.

#162822 added another
validation step to check if entries in a partial reduction chain have
the same scale factor. But the validation was still dependent on the
order of entries in PartialReductionChains, and would fail to reject
some cases (e.g. if the first first link matched the scale of the second
link, but the second link is invalidated later).

To fix that, group chains by their starting phi nodes, then perform the
validation for each chain, and if it fails, invalidate the whole chain
for the phi.

Fixes #167243.
Fixes #167867.

PR: #168036

Avoids regression which caused the revert 6d5f87f.

This is a hack on a hack. We currently have isUniformMMO,
which improperly treats unknown source value as known uniform.
This is hack from before we had divergence information in the
DAG, and should be removed. This is the minimum change to avoid
the regression; removing the aggressive handling of the unknown
case (or dropping isUniformMMO entirely) are more involved fixes.

Upstream ExtVectorElementExpr with rvalue base

We can't do anything meaningful to such functions: they aren't optimizable, and even if inlined, they would bring no code open to optimization.

…66839)

Resolves #165694

To make life easier for future contributors. Note that formatting
changes are due to git clang-format on the touched whitespace-error
lines.

test/Lower/select-case-statement.f90 was still using the old lowering.
Modified the test with FIR generated using the new lowering. Changed the
test to use flang_fc1 instead of bbc and added testing for -O0 and -O1,
since character comparison lowering is done differently at -O0 (uses
runtime function) and -O1 (inlines some cases). Use different FileCheck
prefixes for different optimization levels (CHECK-O0 for -O0, CHECK-O1
for -O1, CHECK for both).

…8292) (#168786)

This reverts commit 6d5f87f.

Previously this failed due to treating the unknown MachineMemOperand
value as known uniform.

…165416)

This PR introduces new debug macros that allow a more fined control of
which debug message to output and introduce C++ stream style for debug
messages.

Changing existing messages (except a few that I changed for testing)
will come in subsequent PRs.

I also think that we should make debug enabling OpenMP agnostic but, for
now, I prioritized maintaing the current libomptarget behavior for now,
and we might need more changes further down the line as we we decouple
libomptarget.

If `HardwareBreakpointTestBase.supports_hw_breakpoints()` returns False,
`SimpleHWBreakpointTest.does_not_support_hw_breakpoints()` returns None,
so the test runs and fails. However, it should be skipped instead.

The test was added in #146602, while `supports_hw_breakpoints()` was
changed in #146609, which was landed earlier despite having a bigger
number.

…econstructing DIE names (#168734)

Depends on: 
* #168725

When compiling with `-glldb`, we repoint the `DW_AT_type` of a DIE to be
a typedef that refers to the `preferred_name`. I.e.,:
```
template <typename T> structure t7;
using t7i = t7<int>;
template <typename T> struct __attribute__((__preferred_name__(t7i))) t7 {};
template <typename... Ts> void f1()

int main() { f1<t7i>(); }
```
would produce following (minified) DWARF:
```
DW_TAG_subprogram
  DW_AT_name      ("_STN|f1|<t7<int> >")
  DW_TAG_template_type_parameter
    DW_AT_type  (0x0000299c "t7i")
...
DW_TAG_typedef
  DW_AT_type      (0x000029a7 "t7<int>")
  DW_AT_name      ("t7i")
```

Note how the `DW_AT_type` of the template parameter is a typedef itself
(instead of the canonical type). The `DWARFTypePrinter` would take the
`DW_AT_name` of this typedef when reconstructing the name of `f1`, so we
would end up with a verifier failure:
```
error: Simplified template DW_AT_name could not be reconstituted:
         original: f1<t7<int> >
    reconstituted: f1<t7i>
```

Fixing this allows us to un-XFAIL the `simplified-template-names.cpp`
test in `cross-project-tests`. Unfortunately this is only tested on
Darwin, where LLDB tuning is the default. AFAIK, there is no other case
where the template parameter type wouldn't be canonical.

Currently the tests for LLVM targets `AArch64` and `ARM` were in the
same directory. But if you only configured LLVM for one target (e.g.,
just `AArch64`, which is how I ran into this), then all tests under the
ARM directory are marked `UNSUPPORTED`.

This patch moves all the tests that are capable of running on
`AArch64`-only targets into a dedicated `AArch64` directory. The tests
that expected a plain `ARM` target were kept in the `ARM` directory.

Drive-by:
* Rename the `dummy-debug-map-amr64.map` to `dummy-debug-map-arm64.map`
(note the typo in `amr64`)

#168619)

I've been working on some scripts that evaluate the parent and child
frame. It's been very annoying that the parent frame has a property but
not the child. So I've added this to the extensions, I would've
preferred to return None, but because the existing impl returns an
invalid SBFrame, so I'm conforming to that API.

```
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> lldb.frame
frame #0: 0x0000555555555200 fib.out`main
>>> lldb.frame.parent
frame #1: 0x00007ffff782a610 libc.so.6`__libc_start_call_main + 128
>>> lldb.frame.parent.child
frame #0: 0x0000555555555200 fib.out`main
```

…ar (#168787)

When downloading bazelisk/buildifier, we use curl, which still returns
exit code zero on HTTP 4xx errors unless we pass --fail. This patch adds
--fail flags so that error messages are more clear.

…168918)

We already know we're looking at BITREVERSE, we can match on the source
operand.

There are several places where we use `llvm::OwningArrayRef`. The
interface to this requires us to first construct temporary storage, then
allocate space and set the allocated memory to 0, then copy the values
we actually want into that memory, then move the array into place.
Instead we can just do it all inline in a single pass by using
`std::vector`. In one case we actually allocate a completely separate
container and then allocate + copy the data over because
`llvm::OwningArrayRef` does not (and can't) support `push_back`.

Note that `llvm::SmallVector` is not a suitable replacement here because
we rely on reference stability on move construction: when the outer
container reallocates, we need the the contents of the inner containers
to be fixed in memory, and `llvm::SmallVector` does not give us that
guarantee.

…pInterface.cpp (NFC)

…62952)

Pyright is an MIT-licensed static type checker and can be found at
    https://github.com/microsoft/pyright
there are also various integrations to use it as an LSP server in
various editors which is the main way I use it.

It's useful on our python scripts to detect issues such as where
functions are called with unexpected types or it's possible to access
obj.attr on an object that doesn't have that attribute. It can be used
without any configuration this config setting causes it to also report
issues with type hints that do not meet our python 3.8 minimum such as
this one from dap_server.py:
```
        init_commands: list[str],
```
subscripting the builtin type like that requires python 3.9 while the
3.8 equivalent is:
```
from typing import List
...
        init_commands: List[str],
```
In practice these scripts still work on 3.8 because type hints aren't
normally evaluated during normal execution but since we have a minimum,
we should fully comply with it.

Note: The error pyright reports for this particular issue isn't great:
```
error: Subscript for class "list" will generate runtime exception; enclose type expression in quotes
```
This is technically correct as it is possible to evaluate type hints at
runtime but I believe anything that would do so would also evaluate the
string form as well and still hit the runtime exception. A better
suggestion in this case would have been the 3.8 compatible `List[str]`.
However, it is better than silently passing code that doesn't confirm to
the minimum.

…168795)

This test explicitly sets the environment for a spawned process. Without
DYLD_LIBRARY_PATH, the spawned process may use a ASAN runtime other than
the one that was used by the parent process That other runtime library
may not work at all, or may not be in the default search path. Either
case can cause the spawned process to die before it makes it to main,
thus failing the test. The compiler-rt lit config sets the library path
variable
[here](https://github.com/llvm/llvm-project/blob/main/compiler-rt/test/lit.common.cfg.py#L84)
(i.e. to ensure that just-built runtimes are used for tests, in the case
of a standalone compiler-rt build), and that is currently used by the
parent process but not the spawned ones.

My change only forwards the variable for Darwin (DYLD_LIBRARY_PATH), but
we **_ought_** to also forward the variable for other platforms.
However, it's not clear that there's any good way to plumb this into the
test, since some platforms actually have multiple library path variables
which would need to be forwarded (see: SunOS
[here](https://github.com/llvm/llvm-project/blob/main/compiler-rt/test/lit.common.cfg.py#L102)).
I considered adding a substitution variable for the library path
variable, but that doesn't really work if there's multiple such
variables.

This reverts commit b725bdb.

This is still causing Darwin failures. There are six tests that are
still failing:
AddressSanitizer-x86_64-darwin.TestCases/Posix.deep_call_stack.cpp
AddressSanitizer-x86_64-darwin.TestCases.scariness_score_test.cpp
AddressSanitizer-x86_64h-darwin.TestCases/Posix.deep_call_stack.cpp
ORC-x86_64-darwin.TestCases/Darwin/x86-64.objc-imageinfo.S
UBSan-Minimal-x86_64-darwin.TestCases.test-darwin-interface.c
UBSan-Minimal-x86_64h-darwin.TestCases.test-darwin-interface.c

There are a couple failure modes:
1. deep_call_stack.cpp and scariness_score_test.cpp are failing due to
   ulimit issues that we have observed previously.
2. objc-imageinfo.S is failing in the x86 variant because I only updated
   the AArch64 variant.
3. test-darwin-interface.c is using subshells, so obviously fails with
   the internal shell. Also looks like this one did not run on my system
   due to it requiring x86_64 Darwin.

…169207)

Fixes #152266

#168885)

Add two more AST nodes, one for a misplaced end-directive, and one for
an invalid string following the OpenMP sentinel (e.g. "!$OMP XYZ").

Emit error messages when either node is encountered in semantic
analysis.

…ant fold (#169217)

Extension to #168726 - ensure we peek through bitcasts to look for
constants (as constant folding will)

DAG should have constant folded this, but we're still fighting the lack
of proper topological sorting.

Fixes #169205

Fold
  any-of (fcmp uno %A, %A), (fcmp uno %B, %B), ... ->
  any-of (fcmp uno %A, %B), ...

This pattern is generated to check if any vector lane is NaN, and
combining multiple compares is beneficial on architectures that have
dedicated instructions.

Alive2 Proof: https://alive2.llvm.org/ce/z/vA_aoM

Combine suggested as part of
#161735

PR: #166823

…tures/Attributes blocks. NFC. (#169223)

Make it easier to use these containers as drop-in replacements for
std::map.

… and flangFrontend (#165277)

This removes the dependency on clangDriver from clangFrontend and
flangFrontend.

This refactoring is part of a broader effort to support driver-managed
builds for compilations using C++ named modules and/or Clang modules.
It is required for linking the dependency scanning tooling against the
driver without introducing cyclic dependencies, which would otherwise
cause build failures when dynamic linking is enabled.
In particular, clangFrontend must no longer depend on clangDriver
for this to be possible.

This change was discussed in the following RFC:
https://discourse.llvm.org/t/rfc-new-clangoptions-library-remove-dependency-on-clangdriver-from-clangfrontend-and-flangfrontend/88773

This PR adds `__builtin_operator_new` and `__builtin_operator_delete`.

The implementation is taken from clang code gen.

The CMake
[`set()`](https://cmake.org/cmake/help/latest/command/set.html) command
does not accept a conditional expression as a value. As a result,
AFFECTED_BY_SWIG_BUG was being set to a string representation of the
condition rather than a boolean value, causing it to always evaluate as
truthy in subsequent if-checks.

This test does not actually need to use the clang driver. Using the
driver means that the environment plays much more into the tests
results. We ran into a situation where the driver decided not to pass
-fopenmp to the cc1 invocation, causing the test to fail.

This also makes the test more consistent with the other OpenMP tests and
should make it slightly faster (no subprocess invocation).

I was the SelectionDAG maintainer (then called code owner) from
aebfacb (requested to take it up by
Evan Cheng) and yielded the role to Justin Bogner as of
d8ed65d.

Co-authored-by: Aiden Grossman <[email protected]>

Fix VPlan SLP check incorrectly bailing out for non-VPInstructions.
Starting from the beginning of the block will include canonical IVs,
which in turn are not VPInstructions. If we hit a non-VPInstruction, we
should conservatively treat is as potentially unvectorizable.

To keep the tests working as expected, refine mayRead/WriteFromMemory
for Load and GEP VPInstructions.

e5edb51 attempted to port this, but
seemed to miss a couple things that still showed up on CI. This patch
fixes up the missing pieces.

#167060)" (#169238)

This reverts commit a52e1af.

That commit reverted a change (making isExpandedFromMacro take a
std::string) that was explicitly added to avoid lifetime issues. We ran
into issues with some internal matchers due to this, and it probably is
not an uncommon downstream use case. This patch restroes the original
functionality and adds a test to ensure that the functionality is
preserved.

https://reviews.llvm.org/D90303 contains more discussion.

…169255)

…64768)

Background: X86 APX feature adds 16 registers within the same 64-bit
mode. PR #164638 is trying to extend such registers for FASTCC. However,
a blocker issue is calling convention cannot be changeable with or
without a feature.

The solution is to disable FASTCC if APX is not ready. This is an NFC
change to the final code generation, becasue X86 doesn't define an
alternative ABI for FASTCC in 64-bit mode. We can solve the potential
compatibility issue of #164638 with this patch.

…Reg (#168661)" (#169219)

Reland d5f3ab8, fix testcases.

This supposes to fix LLVM Buildbot failures after #164768. I don't have
the environment to verify though.

…169262)

Interfaces can be optional: whether an op implements an interface or not
can depend on the state of the operation.

```
// An optional code block for adding additional "classof" logic. This can
// be used to better enable "optional" interfaces, where an entity only
// implements the interface if some dynamic characteristic holds.
// `$_attr`/`$_op`/`$_type` may be used to refer to an instance of the
// interface instance being checked.
code extraClassOf = "";
```

The current `Pass::canScheduleOn(RegisteredOperationName)` is
insufficient. This commit adds an additional overload to inspect
`Operation *`.

This commit fixes a crash when scheduling an `InterfacePass` for an
optional interface on an operation that does not actually implement the
interface.

This is a re-upload of #168499, which was reverted.

SPIR/SPIR-V are generic targets. Assume they support __bf16.